RL-TR-96-119 
Final  Technical  Report 
June  1996 


DECISION  SUPPORT  FOR 
TRANSPORTATION  PLANNING  IN  JOINT 
COA  DEVELOPMENT 


SRI  International 


Sponsored  by 

Advanced  Research  Projects  Agency 


APPROVED  FOR  PUBLIC  RELEASE/  DISTRIBUTION  UNLIMITED. 


19960730  100 


The  views  and  conclusions  contained  in  this  document  are  those  of  the  authors  and  should 
not  be  interpreted  as  necessarily  representing  the  official  policies,  either  expressed  or 
implied,  of  the  Advanced  Research  Projects  Agency  or  the  U.S.  Government. 


Rome  Laboratory 
Air  Force  Materiel  Command 
Rome,  New  York 


This  report  has  been  reviewed  by  the  Rome  Laboratory  Public  Affairs  Office  (PA)  and  is 
releasable  to  the  National  Technical  Information  Service  (NTIS).  At  NTIS,  it  will  be  releasable 
to  the  general  public,  including  foreign  nations. 

RL-TR-  96- 119  has  been  reviewed  and  is  approved  for  publication. 


APPROVED: 


LOUIS  J.  HOEBEL 
Project  Engineer 


FOR  THE  COMMANDER: 


JOHN  A.  GRANIERO 
Chief  Scientist 

Command,  Control  &  Communications  Directorate 


If  your  address  has  changed  or  if  you  wish  to  be  removed  from  the  Rome  Laboratory  mailing  list, 
or  if  the  addressee  is  no  longer  employed  by  your  organization,  please  notify  Rome  Laboratory/ 

(  C3CA),  Rome  NY  1 344 1 .  This  will  assist  us  in  maintaining  a  current  mailing  list. 

Do  not  return  copies  of  this  report  unless  contractual  obligations  or  notices  on  a  specific 
document  require  that  it  be  returned. 


DECISION  SUPPORT  FOR  TRANSPORTATION  PLANNING 
IN  JOINT  COA  DEVELOPMENT 

Marie  A.  Bienkowski,  Ph.D. 


Contractor:  SRI  International 

Contract  Number:  F30602-91-C-0039 

Effective  Date  of  Contract:  20  March  1991 

Contract  Expiration  Date:  28  February  1995 

Short  Title  of  Work:  Decision  Support  for  Transportation 

Planning  in  Joint  COA  Development 
Period  of  Work  Covered:  Jul  91  -  Feb  95 

Principal  Investigator:  Marie  A.  Bienkowski,  Ph.D. 

Phone:  (415)  859-5485 

RL  Project  Engineer:  Louis  J.  Hoebel 

Phone:  (315)  330-3655 


Approved  for  public  release;  distribution  unlimited. 


This  research  was  supported  by  the  Advanced  Research 
Projects  Agency  of  the  Department  of  Defense  and  was 
monitored  by  Louis  J.  Hoebel,  Rome  Laboratory/C3CA, 
525  Brooks  Rd,  Rome  NY  13441-4505. 


REPORT  DOCUMENTATION  PAGE 


Pubic  repaying  bijdin  fv  tNi  cclKtian  of  rfcyrrvikri  is  MtimriadtOMragt  i  hoLr  p«  mapcnsa,  retiring  the  tkn»  for  nvigm^ng  nstnxtiora.  s—fchiTg  axiaig  data  soLrees, 
gathering  ard  martareng  tha  cMa  naeciecl  and  eorrTMng  and  reviwwing  thecoiection  at  tfomTcn  Sard  ccrrrrwts  ragardhg this  txrctan  aatitta  at  any  other  aspect  df  this 
colecticn  of  Hormakan.  hdriig  ■  qgwtim  u  for  reducing  thie  biyden.  to  Waahngon  HeedquaRara  Sarvicac.  Dlrectoratefor  kntarmacian  Operakne  ardPeports,  1 2i  S  Jatfersen 
Davie  Highwray.  Suto  1204,  Arln^arx  VA  22202-4302,  ard  to  the  Office  of  Managamart  and  Budget,  Paperwork  Reduction  Profact  (0704^68).  Waahngtorv  DC  20500 


1 .  AGENCY  USE  ONLY  (Leave  Blant^ 


4.  TrUE  AND  SUBTrUE 


Z  REPORT  DATE 
June  1996 


DECISION  SUPPORT  FOR  TRANSPORTATION  PLANNING  IN 
JOINT  COA  DEVELOPMENT _ 

6.  AUTHOR(S) 

Marie  A.  Bienkowski,  Ph.D. 


7.  PERFORMING  ORGANIZADON  NAME(S)  AND  ADDRESS(ES) 

SRI  International 
333  Ravenswood  Avenue 
Menlo  Park  CA  94025 


a  REPORT  TYPE  AND  DATES  COVERED 
Final  Mar  91  -  Feb  95 


5.  FUNDING  NUMBERS 

C  -  F30602-91-C-0039 

_  PE  -  63728F 

PR  -  G742 
TA  -  00 
WU  -  07 


a  PERFORMING  ORGANIZADON 
REPORT  NUMBER 


9.  SPONSORING/MONfTORING  AGENCY  NAME(S)  AND  ADDRESS(E$) 

Advanced  Research  Projects  Agency 

3701  North  Fairfax  Drive  Rome  Laboratory/C3CA 

Arlington  VA  22203-1714  525  Brooks  Rd 

Rome  NY  13441-4505 


1 1 .  SUPPLEMENTARY  NOTES 


10.  SPONSORING/MONITORING 
AGENCY  REPORT  NUMBER 


RL-TR-96-119 


Rome  Laboratory  Project  Engineer:  Louis  J.  Hoebel/C3CA/ (315)  330-3655 


12a  DISTRIBUTION/AVAILABIUTY  STATEMEMT 


12b.  DISTRIBUTION  CODE 


Approved  for  public  release;  distribution  unlimited. 


1  a  ABSTHACT  (Mwrnxn  200  words) 

COA  generation  is  Interwoven  with  COA  evaluation.  SOCAP  demonstrates  its  ability  to 
aid  in  feasibility  estimation  by  producing  output  for  the  Dynamic  Analysis  and 
Replanning  Tool  (DART)  transportation  feasibility  estimator.  The  output  of  SOCAP 
is  first  used  by  an  intermediate  Force  Module  Enhancer  and  Requirements  Generator 
(FMERG) ,  which  elaborates  the  major  force  list  produced  by  SOCAP  in  order  to  add 
supporting  units  and  their  transportation  requirements.  The  resulting  time-phased 
transportation  data  is  then  passed  to  DART,  which  determines  whether  or  not  the 
proposed  COA  is  feasible. 


14.  SUBJECT  TERMS 

Planning,  Decision  support,  Transportation  feasibility 

1 7.  SECURRY  CUVSSIFICATION  |l  a  SECURITY  CLASSIFICATION  |l  9.  SECURRY 

OF  REPORT  OF  THIS  PAGE  OF  ABSTR 

UNCLASSIFIED  UNCLASSIFIED  UNCLASS 


15l  number  of  pages 
40 _ 

18,  PRICE  CODE 


1  a  SECURITY  CLASSIFICATION  1 9.  SECURITY  CLASSIFICATION  20.  UMITADON  Of 
OF  THIS  PAGE  OF  ABSTRACT 

UNCLASSIFIED  UNCLASSIFIED  UL 


NSN  754001-280.550} 


CONTENTS 


1  OVERVIEW .  1 

1.1  OBJECTIVES .  1 

1 .2  APPROACH .  1 

1.3  SUMMARY  OF  PROJECT .  2 

2  INTEGRATED  FEASIBILITY  DEMONSTRATION  2 .  4 

2.1  JOINT  MILITARY  EMPLOYMENT  AND  DEPLOYMENT 

OPERATIONS .  4 

2.2  EXTENSIONS  TO  Sipe-2  CORE  TECHNOLOGY .  4 

3  TECHNOLOGY  INTEGRATION  EXPERIMENTS .  6 

4  USER  INTERFACE  FOR  SOCAP .  7 

5  SOCAP-ACPT  INTEGRATION  EXPERIMENT .  8 

5.1  INTEGRATION  OVERVIEW .  8 

5.2  KNOWLEDGE  ENGINEERING  AND  SCENARIO .  9 

5.3  SOFTWARE  INTEGRATION .  11 

5.4  EVALUATION  OF  THE  SOCAP-ACPT  TIE .  1 3 

6  REFERENCES .  15 

APPENDIX 

SOCAP-TIE  PROPOSAL 


i 


1  OVERVIEW 


SRI  International  (SRI)  is  pleased  to  submit  this  final  report  on  SRI  Project  2062,  entitled 
Decision  Support  for  Transportation  Planning  in  loint  COA  Development.  This  research  was 
performed  under  Rome  Laboratory  (RL)  contract  F30602-91-C-0039,  which  was  part  of  the 
ARPA-RL  Planning  Initiative  (ARPI)  described  by  Fowler,  Cross,  and  Owens  [1995]. 

1.1  OBJECTIVES 

The  applied  research  projects  that  contributed  to  the  development  of  the  System  for 
Operations  Crisis  Action  Planning  (SOCAP)  aimed  to  produce  tools  that  support  planning  for  crisis 
management.  The  specific  objective  of  the  program  of  applied  research  described  in  this  report  is 
to  test  the  ability  of  artificial  intelligence  (AI)  planning  technology  to  support  the  development  of 
a  decision  aid  to  enable  military  planners  to  develop  more  flexible  and  accurate  joint  military 
courses  of  action  (CO As)  in  a  shorter  period  of  time.  SOCAP  provides  a  key  part  of  an  environment 
in  which  a  military  plarmer  can  rapidly  develop  a  COA,  evaluate  its  feasibility  fi-om  a  number  of 
perspectives,  and  then  modify  it  to  solve  any  problems  detected  in  the  evaluation. 

Our  primary  focus  in  this  work  has  been  on  employing  a  generative  planning  system  to 
produce  COAs,  and  to  use  standard  assessment  models  to  determine  plan  characteristics  such  as 
transportation  feasibility.  Our  approach  had  three  parts:  (1)  to  apply  a  state-of-the-art,  interactive, 
generative  AI  plarming  system,  supported  by  selected  reasoning  techniques,  to  the  operations 
planning  problem,  in  order  to  test  that  planning  system;  (2)  to  develop  an  understandable  user 
interface,  tailored  to  military  planning,  to  that  planning  system;  and  (3)  to  integrate  the  resulting 
system  with  tools  for  plan  evaluation. 

The  technical  challenges  of  this  project  relate  to  the  ability  of  computer-based  generative 
planners  to  meet  the  requirements  of  real-world  problems,  including  (1)  representations  of  a  range 
of  problems;  (2)  a  comprehensible  end-user  interface;  (3)  the  ability  to  handle  large  numbers  of 
operators  and  actions;  (4)  the  management  of  temporal  information;  and  (5)  the  ability  to  add  new, 
or  modify  old  knowledge,  with  ease.  The  integration  of  the  planner  with  supporting  technology 
(such  as  temporal  and  case-based  reasoners,  schedulers,  and  evaluators)  has  been  another 
challenge. 

1.2  APPROACH 

This  project  exemplifies  a  methodology,  driven  by  user  requirements,  for  the  stress  testing  and 
focused  upgrading  of  state-of-the-art  AI  technology.  To  ensure  that  the  technology  meets  a  real 
operational  need,  we  emphasized  cooperation  with  potential  end  users  in  order  to  understand  their 
requirements.  Thus,  in  the  early  years  of  the  project  we  studied  the  requirements  for  plamiing  at  a 
unified  command  (U.S.  Central  Command  [CENTCOM]),  including  the  design  and  testing  of  a 
storyboard  of  the  user  interface  that  illustrated  our  functional  concept  of  operation.  We  applied  an 
AI  planning  system,  called  the  System  for  Interactive  Planning  and  Execution  (SlPE-2  ),  to  produce 


*SiPE-2  is  a  trademark  of  SRI  International.  All  product  names  mentioned  in  this  document  are  the  trademarks  of  their 
respective  holders. 
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a  COA  generation  tool  (SOCAP),  and  integrated  it  with  complementary  ARPI  software  to  produce 
an  integrated  feasibility  demonstration  (IFD2)  whose  target  was  the  operational  community  of 
military  operations  planners.  Not  only  did  this  demonstration  show  the  possibtiities  for  integrating 
separate  technologies  to  attack  an  operational  problem,  but  it  also  identified  several  critical 
technology  gaps.  We  used  the  lessons  learned  fi:-om  IFD2  as  the  basis  for  extending  both  SlPE-2  and 
SOCAP  and  for  performing  several  technology  integration  experiments  (TIEs)  with  other  ARPI 
contractors  to  fill  the  technology  gaps.  After  completing  the  TIEs  and  other  extensions,  we  showed 
that  SlPE-2  and  SOCAP  could  function  as  a  “black  box,”  working  with  an  existing  tool  for  authoring 
and  editing  air  campaign  plans. 

1 .3  SUMMARY  OF  PROJECT 

The  history  of  this  project  can  be  found  in  a  paper  by  Bienkowski,  desJardins,  and  Desimone 
[1994].  In  this  subsection  we  summari2e  that  history.  In  its  mihtary  operations  apphcation,  SOC-^P 
encodes  knowledge  derived  from  a  scenario  used  at  a  mihtary  joint  staff  teaching  college.  Its  user 
interface  guides  a  planner  through  the  interactive  decision-making  needed  for  producing  plans,  and 
displays  the  results  both  textuaUy  and  graphically.  In  early  1992,  SOCAP  was  demonstrated  at 
CENTCOM  in  Tampa,  Florida,  and  at  the  Pentagon,  as  part  of  IFD2.  These  demonstrations  showed 
the  feasibihty  (but  not  the  operational  effectiveness)  of  applying  SOCAP  to  the  generation  of 
large-scale  mihtary  CO  As  and  prehminaiy  operations  plans  (OPLANs)  in  a  crisis  situation.  SOCAP 
generates  and  modifies  distinct  OPLANs  that  embody  employment  plans  for  dealing  with  specific 
enemy  COAs,  and  deployment  plans  for  getting  the  appropriate  combat  forces,  supporting  forces, 
and  their  equipment  and  supphes  to  their  destinations  in  time  for  the  successful  completion  of  their 
mission  (see  Bienkowski  [1994c]  for  an  overview). 

Input  to  SOCAP  (as  shown  in  Figure  1)  includes  threat  assessments,  terrain  analysis,  data  on 
the  apportioned  forces,  planning  goals,  and  operational  constraints.  Unlike  other  systems  that 
might  support  COA  generation,  SOCAP  checks  a  COA’s  consistency  and  adherence  to  constraints, 
represents  the  dependencies  among  the  actions  in  a  COA,  and  can  reason  about  resource  conflicts 
and  utilization.  For  operational  users,  the  main  products  of  SOCAP  are  operations  plans,  estimations 
of  their  feasibihty  from  different  perspectives,  and  a  replanning  capabihty. 

For  operations  planners,  COA  generation  is  interwoven  with  COA  evaluation.  To  demonstrate 
SOCAP’s  abtiity  to  aid  in  feasibihty  estimation,  we  altered  SOCAP  to  produce  output  for  a 
transportation  feasibihty  estimator  called  the  Dynamic  Analysis  and  Replanning  Tool  (DART). 
This  output  is  used  by  an  intermediate  ARPI  system  called  the  Force  Module  Enhancer  and 
Requirements  Generator  (FMERG),  which  elaborates  the  major  force  hst  produced  by  SOCAP 
(e.g.,  in  order  to  add  supporting  units  and  their  transportation  requirements)  and  then  passes  the 
resulting  time-phased  transportation  data  to  DART,  which  determines  if  the  proposed  COA  is 
feasible.  This  integration  constituted  IFD2  [Bienkowski  1995]. 

*1116  last  two  features  are  often  overlooked  by  critics  who  view  Socap  strictly  as  a  mechanism  for  generating 
employment  plans,  and  who  argue  that  process,  as  performed  by  humans,  requires  something  other  than  the 
breadth-first,  hierarchical  decomposition  of  successively  less  abstract  operations.  They  further  argue  that  certain 
evaluation  criteria,  such  as  economy  and  unity  of  force,  carmot  be  captured  in  a  SiPE-like  representation.  Such 
objections,  however,  overlook  Socap’s  most  promising  features,  which  enable  a  human  plarmer  to  set  up  and  modify 
complex  input  to  a  feasibility  estimator  (such  as  a  combat  simulator),  provide  a  powerful  “what-ifing”  c^ability  for 
plan  development,  and  perform  tedious,  detailed  planning. 
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We  integrated  various  displays  into  SOCAP,  such  as  a  map  interface,  menus  and  choice  boxes 
for  interactive  operation,  and  the  like.  SOCAP  contains  various  data  editing  facilities  that  enable  a 
user  to  view  and  modify  world  predicates,  operator  knowledge,  and  class  hierarchy  (the  latter  two 
facilities  were  developed  under  separate  projects).  We  also  identified  a  need  for  an  operator  editing 
tool  that  would  allow  users  to  develop  and  test  new  operators  by  means  of  a  graphical  user  interface 
[desJardins  1994],  We  explored  replanning  and  plan-repair  facilities  and  developed  an  interface 
that  allows  the  user  to  make  use  of  these  capabilities  to  modify  existing  plans,  to  determine  the 
potential  effects  of  changes  in  the  world,  and  to  generate  multiple  alternative  plans. 

This  project  supported  a  port  of  four  AI  systems  from  Symbolics  Common  LISP  to  Lucid 
Common  LISP  for  execution  within  ARPI’s  Common  Prototyping  Environment  (CPE).  These 
systems  are  SlPE-2;  Grasper  (a  graph  layout  and  interface  tool  used  by  SlPE-2);  Gister  (an  evidential 
reasoning  tool);  and  a  reactive  planning  system.  The  project  also  provided  partial  support  for 
porting  from  the  Common  LISP  Interface  Manager  (CLIM)  version  1.0  to  version  2.0  of  the 
Grasper  system.  We  supported  the  integration  of  SOCAP  into  the  CPE  for  the  execution  of  various 
integration  I'lEs.  On  the  basis  of  technology  gaps  identified  as  part  of  IFD2,  we  conducted  several 
riEs,  the  most  notable  of  these  being  the  integration  of  a  temporal  constraint  propagation  system 
(Tachyon)  with  SOCAP  (and,  eventually,  SlPE-2  itself),  and  the  addition  of  scheduling  modifies  into 
SOCAP.  These  l  lEs  are  described  in  detail  by  Bienkowski,  Desimone,  and  desJardins  [1993]  and 
are  summarized  by  Bienkowski  [1994b]. 

We  extended  the  knowledge  encoded  in  SOCAP  about  mfiitary  operations  planning  (based  on 
a  teaching  scenario  obtained  from  a  joint  mfiitary  operations  teaching  college)  to  support  the 
testing  of  resource  utilization  and  replanning.  Our  extensive  use  of  SlPE-2  provided  a  strong  test  of 
its  capabilities  in  this  domain  [Wilkins  and  Desimone  1993]  and  has  produced  a  reusable  database 
of  domain  knowledge  for  mfiitary  planning  (including  a  version  with  no  mfiitary  sensitivity), 
which  has  been  used  by  others  in  ARPI  for  testing. 
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In  the  final  part  of  our  project,  we  applied  SOCAP  to  the  problem  of  generating  air  tasks  firom 
air  objectives  in  the  context  of  air  campaign  planning,  as  captured  in  the  Air  Campaign  Planning 
Tool  (ACPT)  developed  by  ISX  Corporation  (ISX).  This  proof-of-concept  demonstration 
reinforces  the  view  of  SOCAP  as  a  feasible  tool  for  insertion  into  an  operational  system,  thus  further 
demonstrating  SOCAP’s  generahty  and  showing  its  apphcability  to  different  planning  problems. 


2  INTEGRATED  FEASIBILITY  DEMONSTRATION  2 

2.1  JOINT  MILITARY  EMPLOYMENT  AND  DEPLOYMENT  OPERATIONS 

In  the  IFT)2  demonstration  scenario,  SOCAP  generated  deployment  and  employment  actions 
for  achieving  specified  mtiitary  objectives.  These  actions  were  turned  into  a  time-phased 
deployment  plan,  which  was  evaluated  for  transportation  feasibihty  by  a  simulator.  In  IFD2, 
SOCAP  enables  a  joint  operations  planner  to  select  increasingly  detailed  approaches  to  the  mission 
objective  of  protecting  the  territorial  integrity  of  a  country,  until  a  complete  plan  is  rendered.  The 
operations  planner  can  explore  multiple  options  by  making  different  choices  at  choice  points. 

The  development  of  a  COA  proceeds  through  five  levels  of  planning  (although  the 
user-directed  planning  methods  provided  by  SlPE-2  enable  mixing  of  these  levels).  The  levels  are 
as  follows;  (1)  a  mission  type  or  strategy  is  selected  that  will  generate  a  plan  with  a  level  of  force, 
such  as  show-of-force  or  ftiU  defensive  operations);  (2)  specific  enemy  threats  and  their  locations 
are  introduced  into  the  plan  as  goals  to  be  achieved,  and  the  specific  employment  operations  to  be 
used,  the  forces  to  accomphsh  them,  and  the  in-country  destinations  are  selected;  (3)  SOCAP  starts 
to  plan  the  deployment,  and  adds  specific  deployment  actions  into  the  plan,  based  on  the 
deployment  goals  introduced  earher  in  support  of  the  employment  objectives;  (4)  SOCAP  continues 
to  plan  the  deployment  by  adding  intermediate  locations  for  atrlift(s)  (if  needed;  for  example, 
because  of  constraints  on  the  in-country  landing  of  a  strategic  airhft)  and  by  computing  durations 
for  movements;  and  (5)  adds  further  movements  and  durations. 

2.2  EXTENSIONS  TO  SlPE-2  CORE  TECHNOLOGY 

Throughout  this  project,  we  made  a  number  of  modifications  to  SlPE-2  to  enable  it  to  support 
the  requirements  identified  by  the  SOCAP  apphcation.  Some  of  these  modifications  are  described 
in  this  section;  aU  of  them  have  become  part  of  the  standard  release  of  SlPE-2.  Some  of  the  lessons 
learned  in  our  early  apphcation  of  SlPE-2  are  listed  below;  it  is  interesting  to  note  that  during  this 
project  we  have  addressed  all  of  these  issues,  with  the  exception  of  the  aggregation  of  subgoals. 

•  Hierarchical  planning  in  SlPE-2,  involving  multiple  levels  of  detail,  maps  weU  into 
mihtary  operations  planning. 

•  The  sort  hierarchy  is  a  good  representation  of  static  information  about  objects,  and 
its  constraint  language  provides  a  clear  way  to  limit  the  choices  of  values  for 
variables. 
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•  SlPE-2’s  least-commitment  approach  to  variable  binding  (along  with  its  ability  to 
force  instantiations  if  needed)  is  a  way  to  delay  the  selection  of  values  for  arguments 
until  enough  information  for  a  good  choice  has  been  accumulated. 

•  Situational  information  can  be  used  to  define  subgoals  to  be  introduced  into  the  plan 
(e.g.,  each  enemy  threat  can  be  coimtered  with  a  specific  subgoal). 

•  SlPE-2  has  no  temporal  reasoning  facility,  which  would  strengthen  its  resource 
reasoning  method. 

•  Resource  reasoning  could  be  enhanced  to  permit  the  use  of  more  flexible  methods  of 
assigning  resources  to  actions  and  representing  shareable  resources  between  parallel 
actions. 

•  The  aggregation  of  subgoals  (e.g.,  by  time  or  geography)  would  have  made  the 
assignment  of  units  to  counteract  an  enemy  more  efficient. 

•  Users  cannot  specify  the  order  in  which  goals  are  pursued;  and  SlPE-2  cannot  reason 
about  the  order  in  which  to  achieve  goals. 

While  investigating  replanning,  we  altered  the  planning  paradigm  embodied  in  SlPE-2  to 
better  support  a  user’s  needs  for  plan  editing.  This  effort  included  altering  the  way  in  which  goals 
are  selected  for  further  expansion  (i.e.,  the  user  can  now  select  which  goal  to  expand  next); 
enabling  user-directed  copying  of  goals  from  one  level  to  the  next;  permitting  operators  with 
unsatisfied  preconditions  to  be  omitted  from  the  operator  selection  menu;  and  implementing  a  plan 
inputioutput  facility.  This  input/output  facility  is  an  important  prelude  to  tailoring  SOCAP  to  act  as 
a  plan  server  to  any  client. 

One  extension  to  SlPE-2  for  SOCAP  enables  the  introduction  of  a  variable  number  of  goals  into 
a  plan.  This  mechanism,  called  the  parallel  loop  operator,  adds  goals  into  the  developing  plan. 
These  goals  are  based  on  predicates  in  the  database  that  match  a  pattern.  The  parallel  loop  operator 
permits  two  ways  of  identifying  and  describing  a  specific  threat  as  either  specific  enemy  umt(s)  or 
as  a  terrain-based  threat.  If  enemy  unit(s)  are  specified,  a  goal  is  generated  for  every  predicate  that 
specifies  an  immediate  threat,  to  provide  the  introduction  of  an  appropriate  friendly  unit  as  a 
deterrent.  If  the  threat  is  terrain  based,  a  goal  is  generated  for  terrain  locations  that  he  on  predicted 
enemy  avenues  of  approach. 

An  important  aid  to  developing  a  good  COA  is  the  abihty  to  modify  plans  as  new  information 
is  obtained,  or  to  explore  the  robustness  of  a  plan  under  different  circumstances.  In  such  situations, 
a  computer-based  representation  of  the  plan  that  captures  the  interdependencies  among  actions  is 
invaluable.  To  demonstrate  SOCAP’s  abffities  to  support  this  function,  we  adopted  SlPE-2’s 
execution  monitoring  and  replanning  capabihties  to  (1)  perform  backtracking  to  select  a  different 
operator  (thus  enabling  the  generation  of  different  COAs);  (2)  delete  goals  from  the  plan  (e.g.,  for 
an  enemy  threat);  (3)  add  goals  to  the  plan;  (4)  change  the  world  state  (encoded  in  SlPE-2 
predicates)  and  have  the  changes  in  the  plan  automatically  computed  and  shown  to  the  user;  and 
(5)  add  and  delete  resources  from  the  plan,  in  order  to  force  the  reinstantiation  of  variables. 

In  our  development  of  SOCAP,  we  discovered  that  SlPE-2’s  mechanisms  for  reasoning  about 
time  were  inadequate,  that  users  needed  to  be  able  to  tailor  forces,  and  that  support  for  plan 
evaluation  and  inteUigent  resource  assignments  was  critical.  SlPE-2’s  interactive  style  of  planning 
and  general  architecture  permits  other  technologies  to  be  integrated  relatively  easily  to  satisfy  these 
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requirements.  These  other  technologies  consist  of  a  temporal  reasoning  engine,  a  case-based 
module  for  force  selection,  and  a  scheduling  and  capacity  analysis  module.  In  the  next  section,  we 
summarize  our  integration  efforts;  details  can  be  found  in  the  second  annual  report  Pienkowski 
1994a]. 


3  TECHNOLOGY  INTEGRATION  EXPERIMENTS 

SRI  led  or  participated  m  four  TEEs.  These  TTEs  were  unique  in  two  ways:  first,  they  utilized 
existing,  independently  developed,  Al-based  modules  to  supplement  a  mature  generative  planning 
system;  second,  they  added  capabilities  that  had  been  relatively  unexplored  in  generative  planning 
systems.  In  this  work,  we  encountered  research  issues  such  as  the  representation  and  use  of  both 
temporal  information  and  scheduler  feedback  in  a  generative  planner,  apphcation  issues,  such  as 
the  need  to  ensure  that  the  same  domam  knowledge  was  understood  by  all  modules;  and  system 
development  issues  such  as  the  extension  of  the  heuristic  ordering  critics  in  SlPE-2. 

Our  integration  efforts  were  simphfied,  because  the  other  systems  that  we  used  could  be  called 
as  subroutines  by  SOCAP.  This  technique  contrasts  with  an  integration  approach  in  which  each 
module  is  viewed  as  a  separate  agent  with  independent  control  over  an  extended  portion  of  a 
problem,  where  the  communication  of  results  and  the  negotiation  of  tasking  (e.g.,  via  a  blackboard) 
is  critical. 

TTEs  help  to  ehcit  requirements  both  for  the  systems  called  by  SOCAP,  and  for  SOCAP  itself 
(e.g.,  the  handling  of  soft  constraints);  they  are  also  ready-made  way  to  test  whether  requirements 
have  been  fulfilled.  Formally  specified  integration  experiments  give  developers  opportunities  to 
enhance  their  systems,  to  meet  the  requirements  of  other  systems  written  by  developers  who  have 
no  preconceived  notions  of  what  complementary  technology  should  do,  and  are  aware  only  of  their 
own  requirements  for  processing  or  output. 

The  Temporal  Reasoning  TIE  added  temporal  constraint  maintenance  capabilities  to  SlPE-2 
and  explored  additional  capabilities  of  Tachyon  (developed  by  General  Electric’s  Corporate 
Research  Department)  and  Honeywell’s  Time  Map  Manager  (TMM)  that  could  be  useful  for 
SOCAP.  Tachyon  is  now  an  integral  part  of  SlPE-2,  and  is  invoked  as  a  plan  critic  at  the  end  of  each 
planning  level  to  propagate  temporal  intervals  and  durations  among  the  new  actions  added  to  the 
plan  at  that  level. 

The  TIE  between  SOCAP  and  the  Case  Analysis  for  Force  Selection  (CAFS)  system  enabled 
SOCAP  to  send  information  on  the  military  operation,  location,  and  expected  threat  to  CAFS,  and 
have  it  return  an  appropriate  force.  If  no  match  exists  for  the  given  information,  CAFS  can  compute 
the  difference  between  the  closest  case  and  the  given  information,  and  alter  the  force  to  match  the 
new  requirements. 

A  third  TIE  permitted  the  development  of  a  more  effective  method  for  user-assisted  resource 
allocation  in  SOCAP,  one  in  which  the  early  assignment  (prior  to  scheduling)  of  resources  is  based 
on  projections  of  resource  bottlenecks  via  capacity  analysis.  This  method  enables  SOCAP  to  choose 
feasible  deployment  destinations  for  major  forces  during  initial  plan  generation.  To  support 
resource  reasoning,  SOCAP  provides  views  of  the  results  of  the  capacity  analysis  and  then  allows 
the  user  to  assign  or  reassign  resources  on  the  basis  of  those  results. 
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A  final  TEE,  led  by  Bolt  Beranek  and  Newman  Inc.  (BBN),  supported  the  introduction  of 
SOCAP  and  the  TEEs  describe  above  into  the  CPE.  We  led  the  effort  to  develop  a  knowledge 
representation  specification  language  (KRSL)  representation  of  the  communication  in  the  temporal 
reasoning  TIE,  and  aided  in  the  development  of  KRSL  representations  for  the  SOCAP-CAFS 
system  TEE,  and  for  another  TIE  between  SOCAP  and  a  force  module  expansion  mechanism.  This 
activity  led  to  several  extensions  in  KRSL  as  well  as  the  implementation  of  parsers  and  generators 
for  the  new  representations.  SOCAP  was  inserted  into  the  CPE  testbed,  and  used  KRSL-based 
communications  for  aU  TEEs. 


4  USER  INTERFACE  FOR  SOCAP 

The  primary  component  of  SOCAP  that  makes  it  distinct  from  SlPE-2  is  its  user  interface, 
which  makes  available,  to  an  end  user,  the  apphcation  of  SlPE-2  to  mihtary  operations  planning. 
SOCAP  provides  users  with  window-,  graph-,  and  map-based  displays  they  can  employ  to 
manipulate  the  evolving  plan,  to  view  the  current  situation,  and  to  see  enemy  COAs  in  order  to 
visualize  how  forces  are  arrayed  against  a  threat.  SOCAP  includes  SETMAP  (the  situation  mapping 
tool  developed  for  U.S.  Army  Europe),  connected  to  SlPE-2  via  a  robust  InterProcess 
Communication  (EPC)  package  that  supports  both  synchronous  and  asynchronous  communication. 
The  rest  of  the  user  interface  is  written  in  Grasper  (the  same  graph- layout  program  used  by  SlPE-2) 
and  the  CLIM  1.0. 

We  redesigned  and  simphfied  the  SlPE-2  main-screen  display  and  reworked  the  interface  to 
permit  more  focused  viewing  of  the  map.  For  example,  the  map  window  can  be  fixed  in  a  pane 
below  the  primary  user  interaction  window  (covering  the  graph  layout  display  of  the  plan),  and  a 
fixed-location,  color-coded  choice  display  pane  is  used  instead  of  a  popup  window  for  queries  to 
the  user  (e.g.,  about  the  choice  of  operators).  Other  user-interface  enhancements  include  the 
addition  of  popup  windows  for  temporary  text  and  graphics  output,  abort  options  in  several  of  the 
choice  menus,  and  an  option  to  defer  a  resource  conflict  ordering  to  the  next  level  of  planning.  The 
user  interface  also  supports  the  interactive  addition  and  deletion  of  goals. 

SOCAP  contains  a  direct-manipulation  display  of  a  Gantt  chart  that  shows  the  total  usage  of 
resources  in  the  plan;  this  data  is  obtained  from  the  capacity  analysis.  Users  can  modify  this  chart 
to  add  or  delete  a  resource;  or  they  can  use  it  to  edit  the  plan  by  assigning  a  different  resource  to  an 
action  in  the  plan  or  changing  its  time  constraints.  For  the  capacity  analysis  data  plot,  we  used 
BBN’s  SciGraph  package,  which  was  available  as  part  of  the  CPE. 

Users  can  view  and  edit  the  situation  information  that  SlPE-2  is  using  to  generate  plan,  via  the 
information  window.  This  window  shows  the  (dynamic)  world  predicates  that  are  used  by  SlPE-2 
as  planning  guidance  (e.g.,  enemy  threats  to  be  countered,  apportioned  assets,  and  overflight 
privileges).  The  window  can  be  set  up  to  display  any  set  of  predicates.  The  editing  functionality 
provided  for  adding  and  deleting  predicates  uses  the  completion  mechanism  developed  for  the 
operator  editor.  This  CLIM  utility  enables  users  to  request  a  menu  of  completions  by  typing  the 
TAB  character  during  editing. 
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SrPE-2  uses  color  in  its  display  to  highlight  all  actions  that  are  added  or  modified  during 
replanning,  an  important  feature  for  SOCAP’s  replanning  capability.  These  actions  are  indicated  by 
slightly  bolder  node  icons  with  purple  labels  instead  of  red.  (For  monochrome  monitors,  the  label 
font  is  made  bold  and  larger.) 


5  socap-acpt  integration  experiment 

In  the  final  phase  of  our  work,  we  applied  SOCAP  to  the  problem  of  generating  air  tasks  for  air 
campaign  planning,  by  conducting  a  TEE  with  ISX,  the  developers  of  the  ACPT.  ACPT  is  a  plan 
authoring  tool  that  embodies  a  methodology  for  developing  an  air  campaign  by  analyzing  enemy 
centers  of  gravity  and  working  through  the  decomposition  of  objectives  to  produce  a  prioritized 
master  target  list.  One  step  in  this  process  is  to  generate  sets  of  task  objectives  from  a  set  of  given 
higher-level  air  objectives.  To  support  users  in  this  part  of  ACPT,  we  encoded  in  SOCAP  the 
knowledge  necessary  to  generate  a  detailed  plan  for  inflicting  a  specified  level  of  damage  on  a 
potential  set  of  targets.  For  example,  the  target  set  might  include  an  electrical  station,  which  has 
targets  in  primary  and  secondary  categories  (a  generator  is  an  example  of  a  primary  target;  the  air 
defense  network  is  a  secondary  one).  Given  a  specified  level  of  damage  (e.g.,  disable  for  30  days 
or  completely  destroy),  SOCAP  generates  a  coordinated  plan  (part  of  an  air  COA)  for  this  target  and 
others.  It  captures  the  dependencies  needed  to  achieve  the  overall  effect  (e.g.,  taking  out  air  defense 
for  one  target  may  support  attacks  on  other  targets  as  well).  We  integrated  SOCAP  with  ACPT  to 
create  a  proof  of  concept,  which  was  evaluated  with  the  current  ACPT  users. 

5.1  INTEGRATION  OVERVIEW 

Early  on  in  our  planning  for  the  TIE,  we  ascertained  that  SOCAP  could  provide  the 
functionalities  listed  below  to  ACPT.  This  list  was  the  starting  point  for  our  investigations  into  the 
role  of  SOCAP  in  ACPT. 

•  The  automatic  or  interactive  generation  of  detailed  plans  with  maintenance  of 
dependencies  among  actions.  Examples  of  potential  user  interactions  include  the 
selection  of  operators  to  achieve  goals,  the  interactive  addition  or  deletion  of  goals, 
the  selection  of  the  order  in  which  to  decompose  goals,  and  the  editing  of  resources 
to  resolve  conflicts  in  usage. 

•  A  provision  for  backtracking  to  generate  alternatives,  and  to  maintain  several 
alternative  plans  simultaneously. 

•  Support  for  analysis  of  the  effects  of  changes  in  the  world  state  on  the  plan,  followed 
by  plan  repair  and/or  replanning. 

•  Support  for  the  extraction  of  plan  elements  for  display  on  a  map. 

•  A  provision  for  saving  plans  to  files  and  reloading  them  later  for  continued 
development  or  reuse. 

•  Support  for  interactive  operator  development  and  testing. 
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•  Support  for  the  analysis  of  the  utilization  of  the  capacity  of  a  given  resource. 

•  The  use  of  a  temporal  analysis  of  the  objectives  to  correctly  sequence  actions. 

•  The  abihty  to  integrate  several  separately  developed  plans  into  one  plan. 

After  working  with  the  ACPT  developers  and  advisors  at  ISX,  we  determined  that  the  area 
where  SOCAP  could  provide  added  value  was  the  transformation  of  air  objectives  into  detailed  task 
objectives  that  are  associated  with  notional  targets.  The  final  test  of  this  TIE,  then,  was  to 
demonstrate  the  use  of  ACPT  to  develop  an  air  campaign  plan,  with  SOCAP  doing  the  tedious  work 
of  generating  tasks  from  air  objectives.  Different  taskings  would  be  produced  for  different 
situations,  and  SOCAP  would  check  for  the  satisfaction  of  many  constraints  for  which  the  ACPT 
user  is  now  responsible.  (A  complete  proposal  for  the  demonstration  of  the  TIE  is  presented  in  the 
appendix.) 

We  further  identified  four  major  points  of  emphasis  in  the  demonstration,  and  structured  that 
the  scenario  so  to  highhght  those  points.  These  points  of  emphasis  areas  follow:  (1)  SlPE-2  can 
generate  alternative  task  objectives  for  a  given  air  objective;  (2)  SlPE-2  can  analyze  the 
dependencies  among  the  parts  of  a  plan,  to  show  what  changes  take  place  when  the  assumptions 
made  during  planning  change;  (3)  SlPE-2  can  generate  database  queries  that  narrow  the  fist  of 
potential  targets  instead  of  suggesting  a  notional  target;  and  (4)  SlPE-2  can  show  the  effects  on  a 
plan  of  changes  in  planning  assumptions. 

Other  features  that  we  thought  would  be  useful  could  not  be  included  in  the  TIE.  SOCAP  could 
support  a  simple  scheme  for  handling  user  preferences,  by  using  SlPE-2’s  capabihty  to  specify  the 
order  in  which  apphcable  operators  are  applied  to  planrting  goals.  SOCAP  could  also  support  the 
analysis  of  plans  that  violate  rules  of  engagement  or  other  constraints  on  warfare,  by  presenting 
these  plans  to  the  user  after  plans  with  less  serious  violations  had  been  considered.  The  full 
integration  of  SOCAP  with  ACPT  would  also  require  a  “plan  comparator,”  which  we  envisioned  as 
combined  of  a  plan  analysis  and  user  interface  tool  that  could  highhght  the  significant  differences 
between  two  similar  plans. 

5.2  KNOWLEDGE  ENGINEERING  AND  SCENARIO 

Our  first  task  in  integrating  SOCAP  and  ACPT  was  to  construct  a  scenario  and  perform  the 
required  knowledge  engineering  to  support  the  demonstration.  For  SOCAP,  we  need  to  specify  the 
state  of  the  world  when  planning  starts,  including  geography,  enemy  forces,  and  target  information 
(at  a  suitable  level  of  detail).  For  the  proof-of-concept  TIE,  we  used  only  a  small  subset  of  the 
elements  that  would  be  represented  in  a  real  scenario. 

SOCAP  uses  the  following  types  of  information: 

•  Static  world  knowledge  representing  the  situation 

-  Target  types  (“threats”)  and  their  characteristics 

-  Primary  and  secondary  targets 

-  Geographic  and  terrain  information 

-  Friendly  airstrike  capabhities,  and  their  locations 
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•  Dynamic  world  knowledge,  represented  as  constraints 

-  Overflight  privileges 

-  Amount  of  damage  desired 

•  Operators  that  introduce  actions  into  the  plan 

-  Preconditions  for  operation  apphcation 

-  Plots  containing  actions,  further  goals,  etc. 

-  An  abstraction  hierarchy  for  goals  (e.g..  Achieve  Air  Supremacy,  and  Degrade 
Enemy  C2). 

We  developed  a  smaU,  unclassified  scenario  based  on  a  more  detailed  scenario  by  ISX,  about 
an  air  operation  in  a  foreign  country.  We  provided  ISX  with  a  hst  of  the  potential  targets  that  we 
would  like  to  have  in  the  database,  based  on  this  scenario.  The  scenario  includes  two  phases;  a 
limited  response  and  a  moderately  intense  air  campaign  in  response  to  increased  hostihties.  The 
world  knowledge  representing  the  scenario  includes  a  simplified,  area-based  representation  of  the 
country’s  geography  and  simple  descriptions  of  targets.  Rules  of  engagement  (ROEs)  had  not  been 
addressed  by  ACPT;  those  that  were  relevant  to  this  scenario  were  developed  and  encoded,  to 
enable  us  to  demonstrate  SOCAP’s  replanning  functionahty.  The  names  of  operators  that  resolve  air 
objectives  into  air  tasks  are  as  follows;  disrupt  transport,  destroy  artillery, 
destroy  POL,"*"  degrade  of  fense,  degrade  NBC,^  achieve  local  air 
superiority,  and  deny  air  attacks. 

In  our  hypothetical  scenario,  aUied  forces  in  a  foreign  theatre  of  operations  respond  to 
threatening  actions  from  a  northern  neighbor  across  a  demihtarized  zone  (DMZ).  These  actions 
include  a  substantial  troop  buildup  near  the  DMZ,  limited  cross-border  raids,  and  artiUeiy  attacks 
that  have  provoked  long-range  artiUery  exchanges  between  Mendly  and  enemy  forces.  Though  the 
risk  of  a  massive  cross-border  invasion  from  the  north  is  substantial,  it  is  felt  that  enemy  actions  to 
date  have  been  primarily  provocative  in  nature.  A  COA  involving  a  limited  response  has  therefore 

been  adopted. 

The  purpose  of  the  limited  response  is  to  protect  the  DMZ  with  defensive  and  limited 
preemptive  measures,  avoiding  actions  that  are  deemed  to  be  highly  provocative  and  escalatory. 
Therefore  the  operation  is  to  be  conducted  under  substantial  constraints,  which  are  reflected  in  the 
ROEs. 

In  addition  to  the  limited  response  (which  is  to  start  immediately),  a  foUow-up  operation  is  to 
be  planned  as  a  contingency  measure  to  counter  a  substantial  ground  attack  from  the  north.  This 
operation  is  to  be  broader  in  scope  than  the  limited  response,  and  fought  with  less  restrictive  ROEs. 
Its  purpose  is  to  restore  the  status  quo  ante  and  to  deter  subsequent  aggression. 


*We  do  not  Hst  all  of  the  detailed  or  smaller  scenarios  here;  a  list  of  such  scenarios  can  be  obtained  from  the  author  of 
this  report 

''TOL:  petroleum,  oil,  and  lubricants. 

*NBC;  nuclear,  biological,  and  chemical  (sc.  weapons). 
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In  this  scenario,  the  limited  response  is  designated  Phase  1,  and  the  broader  response  Phase  2. 
Table  1  lists  some  of  the  rules  of  engagement  and  objectives  for  both  phases. 


Table  1 .  Scenario  Rules  of  Engagement  and  Objectives 


PHASE  1 

PHASE 2 

ROES 

5  km.  radius  no-strike  zone  around  civilian 
population  centers 

No  targets  further  than  200  km.  from  the 
DMZ  may  be  attacked 

Troop  concentrations  may  not  be  attacked 
Water  and  electric  infrastructure  upon 
which  civilians  are  heavily  dependent  may 
not  be  attacked.  Transportation 
infrastructure  (road/bridge  and  rail)  may  be 
attacked 

2  km.  radius  no-strike  zone  around  civilian 
population  centers;  NBC  targets  are 
exempt  from  this  restriction 

Objectives 

Disrupt  transportation  infrastructure  that 
supports  the  area  of  troop  buildup 

Destroy  artillery  within  range  of  DMZ 

Destroy  logistical  support  for  potential 
invasion 

Defend  against  further  incursions  and  raids 
Disrupt  transportation  infrastructure  that 
supports  the  area  of  troop  buildup 

Destroy  artillery  within  range  of  DMZ 

Destroy  logistical  support  for  potential 
invasion 

Defend  against  further  incursions  and  raids 

Defeat  enemy  in  DMZ 

Degrade  enemy’s  capability  to  conduct 
offensive  warfare 

Destroy  enemy’s  NBC  capability 

5.3  SOFTWARE  INTEGRATION 

A  major  portion  of  the  integration  effort  was  designing  and  implementing  the  software 
integration  of  SOCAP  and  ACPT,  including  the  creation  of  a  language  for  passing  air  objectives  into 
SOCAP,  and  returning  output  tasks  to  ACPT.  In  this  TIE,  SOCAP,  which  can  operate  in  both 
automatic  and  interactive  modes,  was  used  in  automatic  mode.  Part  of  the  TIE  development  effort 
was  to  modify  SlPE-2  to  support  a  client-server  style  of  interaction  with  ACPT.  In  this  way,  ACPT 
can  send  data  to  SOCAP,  have  it  generate  alternative  plans  (in  a  batch  style  of  processing),  and 
return  the  plans  for  display  by  ACPT.  We  wrote  code  to  enable  SlPE-2  to  automatically  generate  all 
possible  plans  and  register  each  one  so  that  the  SlPE-2  display  mechanism  can  show  each,  as 
needed. 

Other  issues  that  arose  during  the  TIE  development  were  ways  to  enable  SOCAP  to  generate 
database  queries  for  the  ACPT  target  database  (for  notional,  not  specific,  targets).  The  range  of 
queries  was  limited  to  those  for  which  relations  were  already  specified  in  the  database  schema;  we 
defined  this  schema  by  analyzing  the  code  that  ISX  produced  to  implement  a  database  mediator  for 
the  ACPT  databases. 


We  created  and  refined  an  interface  specification  for  communicating  plan  and  situation 
information  to  and  from  SOCAP  and  ACPT.  Programmatically,  the  interface  is  simple:  SOCAP  and 
ACPT  exchange  data  by  reading  and  writing  files.  Only  after  several  iterations,  however,  could  we 
agree  upon  an  interface  language  for  passing  data  back  and  forth.  On  the  ACPX  side,  we  designed 
the  user  interface  for  the  new  window  in  ACPT  to  support  the  task  generation  capabihties  provided 
by  SOCAP;  we  also  provided  data  for  the  target  database  needed  for  the  scenario  we  developed. 

To  support  the  demonstration  of  the  TIE  fi'om  SlPE-2  (without  running  ACPT),  we  enhanced 
SlPE-2’s  movie  mode  to  show  the  plan  expansion  as  it  occurs,  enhancing  the  use  of  color  to 
highlight  important  parts  of  the  plans. 

We  also  found  it  necessary  to  revise  the  way  SlPE-2  supports  planning,  so  that  it  would  fit  in 
with  ACPT’s  model.  SlPE-2  normally  operates  on  one  goal,  forming  a  complete  plan  to  achieve  it. 
However,  ACPT  users  consider  air  objectives  one  at  a  time,  collecting  (but  not  merging)  them  as 
they  select  the  task(s)  that  must  be  perfomed  to  achieve  each  air  objective.  Although  ACPT  was 
modified  for  this  TIE,  to  support  the  consideration  of  alternative  task  objectives  for  a  given  air 
objective,  it  does  not  support  the  notion  of  a  set  of  objectives  (either  air  or  task)  being  unified  into 
a  plan,  and  having  alternatives  at  that  unified  level.  Thus,  ACPT  unphcitly  assumes  that  the  plans 
for  each  air  objective  are  independent.  To  merge  these  two  disparate  views  of  planning,  we 
modified  SlPE-2  to  accept  a  set  of  air  objectives  for  which  to  plan  tasks,  and  to  consider  each  task 
choice  for  each  air  objective  as  an  alternative  plan. 

Internally,  SlPE-2  still  represents  alternative  tasks  at  the  unified  plan  level.  This  method  of 
representation  enables  it  to  detect  dependencies  between  tasks  and  to  take  advantage  of  them  to 
make  a  plan  more  efficient).  We  wrote  complex  code  to  extract  and  present  single-task  alternatives 
to  ACPT,  and  then  to  combine  ACPT-selected  alternatives  into  a  unified,  vafid  SlPE-2  plan  for  aU 
the  given  air  objectives.  This  modification  required  that  parts  of  several  plans  be  merged  to  create 
a  new  one. 

Some  of  the  contingencies  that  we  considered  were  as  follows;  first,  a  user  of  ACPT  may 
never  issue  a  command  to  select  an  alternative  for  an  objective;  in  such  cases  SlPE-2  uses  its  default 
plan.  Second,  a  user  can  make  selections  for  only  a  subset  of  the  objectives;  and  SlPE-2  therefore 
fills  in  the  others  from  the  default  (unless  dependencies  require  a  different  choice).  Third,  a  later 
ACPT  selection  is  ignored  (and  warning  messages  are  displayed  to  the  user)  if  it  conflicts  with 
dependencies  from  earher  selections.  Finally,  if  all  selections  made  by  ACPT  are  in  one  alternative 
plan,  then  that  plan  becomes  the  default. 

This  new  capabihty  of  SIPE-2  has  been  tested  on  the  following  complex  test  case.  First, 
ACPT  sends  eight  objectives  to  SlPE-2,  which  finds  three  alternative  plans.  SlPE-2  sends  aU 
single-objective  alternatives  from  the  three  plans  to  ACPT.  ACPT  then  picks  one  alternative  from 
each  of  the  unified  SlPE-2  plans;  one  of  these  selected  alternatives  has  dependencies  on  other 
objectives  not  in  the  default  plan.  Thus,  SlPE-2  must  construct  a  new  plan  from  the  existing  ones 
by  regrouping  them. 
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5.4  EVALUATION  OF  THE  SOCAP-ACPT  TIE 


5.4.1  Evaluation  Metrics 

We  would  have  preferred  to  evaluate  the  SOCAP- ACPT  TIE  by  means  of  an  automated 
analysis  of  effectiveness  of  the  plan  generated  by  SOCAP.  However,  such  an  analysis  would  require 
a  more  extensive  knowledge  engineering  effort  than  we  could  have  performed  under  the  current 
contract;  further,  no  tool  is  currently  available  that  can  evaluate  a  plan  and  produce  feedback  on  it. 
To  achieve  the  more  modest  goals  of  the  TIE,  we  instead  formulated  the  following  criteria  for  the 
success  of  the  demonstration. 

•  Is  the  task  generator  operationally  vahd?  Do  the  SOCAP  knowledge  base  and 
processing  methodology  (as  much  as  is  visible  to  the  user  through  the  ACPT 
interface)  reflect  the  way  an  operational  user  would  perform  the  task?  Are  any 
incorrect  knowledge,  obvious  omissions,  or  test  cases  present  that  would  validate  the 
system  or  stress  test  its  capabdities? 

•  How  does  the  quahty  of  the  generated  plans  compare  to  that  of  plans  that  a  human 
planner  would  produce?  How  might  the  plans  be  optimized  or  prioritized  to  reflect  a 
human  planner’s  evaluation  function  for  plan  quahty? 

•  How  fast  does  the  planner  work?  What  scale  of  knowledge  (e.g.,  how  many  operators 
and  predicates)  would  be  needed  to  generate  a  reahstic  plan  (on  a  scale  somewhat 
smaller  than  that  of  Operation  Desert  Storm),  and  how  would  SOCAP  perform  with 
that  amount  of  data? 

•  Are  any  essential  features  missing?  How  are  they  essential,  and  what  value  would 
they  add  to  the  system?  What  nonessential  missing  features  might  be  useful? 

5.4.2  After-Action  Review  of  the  November  1994  TIE  Demonstration 

In  this  subsection  we  describe  an  after-action  review  of  the  TIE  demonstration  presented  at 
Rome  Laboratory  on  15  November  1994.  The  agenda  for  the  TIE  was  broadened  in  scope,  to  make 
better  use  of  the  time  of  the  attendees  who  were  interested  in  related  activities  at  RL.  Mr.  Louis 
Hoebel  (RL)  first  introduced  the  planning  and  scheduling  work  performed  under  ARPL  Ms.  Karen 
Alguire  demonstrated  some  scheduling  work;  and  Mr.  Gary  Edwards  of  ISX  presented  an  overview 
of  that  portion  of  air  campaign  planning  covered  by  ACPT,  and  described  ACPT  itself. 

Dr.  Marie  Bienkowski  of  SRI  then  presented  background  information  on  the  SOCAP- ACPT  TIE, 
and  Messrs.  Joe  Roberts  and  Earl  Baugh  of  ISX  and  Mr.  Thomas  Lee  of  SRI  conducted  the  T  IE. 

Technically,  this  TIE  constituted  the  “final  exam”  specified  in  the  proposal  to  ARPA  for  the 
T  IE  demonstrations,  appended  to  this  report.  The  level  of  interaction,  however,  between  potential 
end  users  and  the  SOCAP- ACPT  system  was  low,  because  the  attendees  were  also  concerned  with 
other  activities.  In  March  1995  we  therefore  conducted  another  demonstration,  described  in  the 
following  subsection. 
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5.4.3  After- Action  Review  of  the  March  1995  TIE  Demonstration 

Overview.  SRI  and  RL  arranged,  with  ISX,  to  present  another  TIE  to  Checkmate  personnel 
(ACPT  users)  in  Washington,  D.C.  Two  members  of  Checkmate  were  present.  Col  Bob  Plebanek 
and  LTC  Phil  Kellerhas.  Mr.  Hoebel  and  Mr.  John  Lemmer  (RL),  Mr.  Roberts  (ISX),  and  Mr.  Lee 
and  Dr.  Bienkowski  (SRI)  were  also  present. 

After  a  brief  introduction  overview  of  ARPI,  we  presented  an  overview  of  the  TIE.  The  four 
criteria  listed  above  in  Subsection  5.1  were  emphasized,  to  highhght  the  potential  of  the 
technology.  Mr.  Lee  gave  the  TIE  demonstration.  He  first  showed  part  of  ACPT  to  set  the  stage, 
then  the  “Generate  Plan”  interface  window  from  ACPT  (showing  SOCAP results).  SOCAP  returned 
alternatives  to  ACPT,  which  displayed  the  alternatives  as  a  list  of  possible  tasks.  Links  were 
graphically  displayed  to  show  the  interdependencies  among  tasks,  which  Col  Plebanek  thought 
useful.  We  did  not  run  the  target  database,  but  described  the  target  culling  feature,  which  prompted 
a  discussion  of  target  prioritization  (see  below).  We  also  showed  the  replanning  capability  via  the 
SlPE-2  interface. 

Discussion.  Col  Plebanek  felt  that  the  planner’s  actions  were  difficult  to  track;  he  was  not 
comfortable  about  relinquishing  control  of  the  planning  process  to  a  “black  box.”  We  were  not  sure 
whether  he  felt  that  there  was  any  role  in  this  part  of  the  process  for  a  completely  automated 
(vs.  interactive)  plarmer.  Our  impression,  however,  was  that  an  automatic  planner  would  be 
acceptable  if  the  human  planners  are  kept  apprised,  in  domain  terms,  of  the  automated  planner’s 
decisions  and  how  they  are  being  made — especially  decisions  based  on  trade-offs.  The  human 
plarmers  should  also  be  able  to  override  the  decisions  that  they  do  not  hke:  thus,  the  interaction 
should  support  a  plan  editing  capability.  Col  Plebanek  also  observed  that  a  capability  to  “learn”  at 
each  step  of  planning  would  be  an  important  addition  to  the  system,  and  that  both  the  situation  and 
the  commander’s  style  should  be  able  to  influence  the  final  form  of  a  plan. 

Col  Plebanek  was  interested  in  plan  evaluation — he  wanted  to  know  the  criteria  the  planner 
was  using  to  make  choices,  and  he  wanted  to  be  able  to  reflect  on  the  cost  of  certain  actions.  In 
particular,  he  wanted  a  cost-benefit  analysis  of  alternative  actions  and  the  capability  to  hst,  a  priori, 
the  criteria  on  which  the  analysis  would  be  based. 

There  were  two  salient  points  where  he  thought  technology  could  be  used.  One  was  to  assess 
the  priority  of  tasks.  Currently,  this  assessment  is  subjective  and  is  performed  by  a  low-ranking 
staff  member;  Col  Plebanek  would  like  the  assessment  to  be  more  objective.  Technology  could  also 
be  used  to  maximize  the  value  of  resource  allocation. 

Future  Work.  As  a  result  of  this  demonstration,  we  received  some  valuable  guidance  on  where 
to  focus  our  continuing  efforts.  Col  Plebanek  appeared  wilting  and  ready  to  provide  domain 
expertise  to  help  us  learn  more  about  campaign  planning,  and  to  encode  that  expertise  into  a 
planning  and  plan-evaluation  system. 

A  key  operational  feature  of  this  TIE  was  the  link  between  the  air  objectives  and  the 
task/target  Hst,  which  helped  to  show  the  effect  on  the  decision-making  process  of  resources  and 
target  priorities.  Col  Plebanek  would  Hke  a  capabiHty  for  helping  planners  understand  the 
trade-offs  that  are  made  in  the  course  of  plan  development. 
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In  our  future  work  on  this  TIE,  we  will  create  several  variations  on  the  display  that  wiQ  show 
the  planning  process  in  more  detail;  i.e.,  the  variations  will  provide  more  justification  for  the 
actions  SlPE-2  chooses,  and  will  enable  the  users  to  ask  questions  about  the  developed  plan.  We  wfil 
show  the  variants  to  Qieckmate  personnel,  and  gamer  feedback  on  the  best  presentation.  Instead 
of  adding  more  knowledge  to  the  TIE  demo,  we  will  add  an  explanation  capability  to  ensure  the 
traceability  of  decisions,  and  code  some  simple  quantitative  information  on  building  the  prioritized 
target  list.  We  believe  that  an  increased  emphasis  on  plan  evaluation,  including  the  presentation  of 
evaluation  results,  will  be  of  interest  to  users.  We  will  validate  this  belief  by  means  of  storyboard 
interfaces  showing  the  evaluation  results  that  can  be  produced,  computationally,  firom  the 
generated  plans. 
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Appendix 

SOCAP-TIE  PROPOSAL 


socap-acpt  tie  proposal 


[The  following  proposal  was  submitted  to  ARPA  and  RL  to  use  existing  contract  funds  to 
conduct  a  TIE  with  ISX  and  RL  personnel.  The  original  proposal  was  sent  and  delivered  as  an 
e-mad  message.] 


Technology  Integration  Experiment  (TIE):  SOCAP-ACPT 

A.1  PLAYERS 

SRI,  ISX,  Rome  Laboratory  (John  Lemmer,  Louis  Hoebel) 

A2  DESCRIPTION 

This  TIE  will  use  the  planning  abihties  of  SOCAP  to  enhance  the  Air  Campaign  Planning 
Tool  (ACPT).  More  than  half  the  effort  in  producing  a  typical  air  campaign  plan  involves  turning 
air  objectives  into  specific  tasks,  and  this  work  is  often  tedious.  This  TIE  will  use  SOCAP  to 
generate  alternative  sets  of  tasks  for  an  air  objective  and  let  users  choose  among  them  (or  choose 
to  enter  their  own.)  Only  a  small  proof-of-concept  demonstration  for  a  specific  scenario  will  be 
implemented.  Both  SOCAP  and  ACPT  will  run  on  Sun  SPARCstations. 

A.3  TASKS 

A3.1  Design  Overall  Approach 

This  includes  defining  a  scenario  for  the  demonstration,  deciding  on  the  breadth  and  depth  of 
knowledge  to  be  encoded  in  SOCAP,  and  defining  an  interface  specification  (i.e.,  a  language  for  air 
objectives  to  be  given  to  SOCAP  and  a  language  for  tasks  to  be  given  to  ACPT).  This  task  involves 
both  SRI  and  ISX.  While  we  will  not  attempt  to  encode  this  specification  using  KRSL,  we  will 
make  the  results  available  to  the  KRSL  maintainers  for  consideration  as  a  possible  extension  to  the 
language. 

A.3.2  Knowledge  Engineering 

Encode  knowledge  about  ACP  into  SOCAP.  This  involves  knowledge  about  the  world, 
constraints,  targets,  and  the  actions  that  can  be  used  to  achieve  air  objectives.  This  task  will 
primarily  be  done  by  SRI,  with  some  consultation  fi'om  ISX. 

A.3.3  Development  and  Testing 

Integrate  the  c^abihties  of  SOCAP  into  ACPT,  perform  initial  testing  at  a  location  to  be 
agreed  upon  with  the  government,  respond  to  feedback  from  initial  test,  and  dehver  a  final 
proof-of-concept  demonstration. 
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A.4  FINAL  EXAM 

Demonstrate  ACPT  being  used  to  develop  an  air  campaign  plan,  with  SOCAP  doing  most  of 
the  tedious  woric  of  generating  tasks  from  air  objectives.  Ehfferent  taskings  will  be  produced  for 
different  situations.  SOCAP  wiU  check  for  satisfaction  of  many  constraints  that  the  user  is  now 
responsible  for  checking  in  ACPT. 

A.5  SCHEDULE  AND  LEVEL  OF  EFFORT 


Table  A-1.  Tasks 


TASK 

START  DATE 

END  DATE 

3.1 

23  May  1994 

1  June  1994 

3.2 

1  June  1994 

24  June  1994 

3.3 

27  June  1994 

22  July  1994 

[This  demonstration  will  be  a]  proof  of  concept,  to  be  funded  under  existing  contracts. 

A.6  REQUIREMENTS  TO  CPE  GROUP 

Existing  tools;  SOCAP,  ACPT. 

New  tools:  None. 

Knowledge/data:  general  air  campaign  planning  knowledge;  unclassified  target  data  and 
scenario. 

A.7  REQUIREMENTS  TO  IFD  GROUP 

Knowledge  and  expertise  to  be  provided  by  ISX. 

Feedback:  See  above. 

New  Components;  None 

A.8  RESULTS  FOR  IFD 

Capabilities:  see  final  exam. 

A.9  RESULTS  FOR  CPE 

Capabihties:  see  final  exam. 
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DISTRIBUTION  LIST 


addrsssas 


number 
of  copies 


LOUIS  J.  HOEBEL  5 

ROME  LABORftTQRT/C3CA 
525  BROOKS  RO 
ROME  NY  13441-4505 


SRI  INTERNATIONAL  3 

333  RAVENSWOOQ  AVE 
MENLO  PARK  CA  94025 


ROME  LABORATORY/SUL  1 

TECHNICAL  LIBRARY 
26  ELECTRONIC  PKY 
ROME  NY  13441-4514 


ATTENTTON:  DTIC-OCC  2 

DEFENSE  TECHNICAL  INFO  CENTER 

8725  JOHN  J.  KINGMAN  ROAD,  STE  0944 

FT.  BELVOIR,  VA  22060-6213 


ADVANCED  RESEARCH  PROJECTS  AGENCY  1 

3701  NORTH  FAIRFAX  DRIVE 
ARLINGTON  VA  22203-1714 


DR  JAMES  ALLEN  1 

COMPUTER  SCIENCE  OEPT/SLDG  RM  732 

UNIV  CF  ROCHESTER 

WILSON  BLVO 

ROCHESTER  NY  14627 

DR  YIGAL  ARENS  1 

USC-ISI 

4676  ADMIRALTY  WAY 
MARINA  DEL  RAY  CA  90292 


OR  MARIE  A,  8IENKQWSKI  1 

SRI  INTERNATIONAL 

333  RAVENSWaOO  AVE/EK  337 

MENLO  PRK  CA  94025 


DL-1 


DR  MARK  S.  BODOY 
HONEYyetL  SYSTEMS  &  RSCH  CENTER 
3660  TECHNOLOGY  DRIVE 
MINNEAPOLIS  MN  55418 


OR  MARK  SURSTEIN 
B8M  SYSTEMS  £  TECHNOLOGIES 
10  MOULTON  STREET 
CAMBRIDGE  MA  02138 


OR  GREGG  COLLINS 

INST  FOR  LEARNING  SCIENCES 

1890  MAPLE  AVE 

EVANSTON  IL  60201 


MR.  RANDALL  J.  CALISTRI-YEH 
ORA  CORPORATION 
301  OATES  DRIVE 
ITHACA  NY  14850-1313 


OR  STEPHEN  E.  CROSS 
SCHOOL  OF  COMPUTER  SCIENCE 
CARNEGIE  MELLON  UNIVERSITY 
PITTSBURGH  PA  15213 


MS.  LAURA  DAVIS 
CODE  5510 

NAVY  CTR  FOR  APPLIED  RES  IN  AI 
NAVAL  RESEARCH  LASORATDRY 
WASH  DC  20375-5337 

DR  THOMAS  L.  DEAN 
BROWN  UNIVERSITY 
DEPT  OF  COMPUTER  SCIENCE 
P.O.  SOX  1910 
PROVIOENCE  RI  02912 

DR  PAUL  R.  COHEN 
UNIV  OF  MASSACHUSETTS 
COINS  DEPT 
LEDERLE  GRC 
AMHERST  MA  01003 

OR  JON  DOYLE 

LABORATORY  FOR  COMPUTER  SCIENCE 
MASS  INSTITUTE  OF  TECHNOLOGY 
545  TECHNOLOGY  SQUARE 
CAMBRIOGc  MA  Q2139 


DL-2 


HR.  STU  DRAPER 

HITRE 

EASLE  CENTER  3,  SUITS  8 

O'PALLON  IL  62269 

1 

HR.,  GART  EOyARDS 

4353  PARK  TERRACE  DRIVE 

W£STLA,K£  VILLACA  91361 

1 

MR.  RUSS  FR,eM 

GENERAL  ELECTRIC 

MGORESTOMN  CORPORATE  CENTER 

BLDG  ATK  145-2 

HOORESTOWN  MJ  08057 

1 

DR  MICHAEL  FEHLING 

STANFORD  UNIVERSITY 

ENGINEERING  ECO  SYSTEHS 

STANFORD  CA  94305 

1 

DR  KRISTIAN  J.  HAMMOND 

UNIV  OF  CHICAGO 

COMPUTER  SCIENCE  DEPT/RYISS 

1100  E.  58TH  STREET 

CHICAGO  IL  60637 

1 

RICK  HAYES-ROTH 

CIMFLEX-TEKNOWLEOGE 

1810  EM3ARCAOERO  RO 

PALO  ALTO  CA  94303 

1 

OR  JIM  HENDLER 

UNIV  OF  MARYLAND 

DEPT  OF  COMPUTER  SCIENCE 

COLLEGE  park  MO  20742 

1 

HR.  MORTON  A.  HIRSCHSERG,  DIRECTOR 

US  ARMY  RESEARCH  LABORATORY 

ATTN;  AMSRL-CI-CB 

ASEROEEN  PROVING  GROUND  MD 

21005-5066 

1 

MR,  MARK  A.  HOFFMAN 

ISX  CORPORATION 

1155  NORTHCHASE  PARKWAY 

MARIETTA  GA  30067 

1 

OL-3 

DR  RON  LfiRSEN 

NAVAL  CMD,  CONTROL  £  OCEAN  SUR  CTR 
RESEARCH,  DEVELOP,  TEST  t  EVAL  DIV 
CODE  444 

SAN  DIEGO  CA  92152-5000 

NR.  RICHARD  LOME  CAP-10) 

SRA  CORPORATION 

2Q0G  I5TM  STREET  NORTH 

ARLINGTON  VA  22201 


NR.  TED  C.  KRAL 
SON  SYST5NS  I  TECHNOLOGIES 
4015  HANCOCK  STREET,  SUITE  101 
SAN  DIEGO  CA  92110 


OR.  ALAN  MEYROWITZ 

NAVAL  RESEARCH  LA8QRAT0RY/CQDS  5510 
4555  OVERLOOK  AVE 
^ASH  DC  20375 


ALICE  i^ULVEHILL 
NITRE  CORPORATION 
SURLINGTON  RO 
^/S  K-302 
SEDFORO  MA  01730 

OR  DREW  MCOERNOTT 
YALE  COMPUTER  SCIENCE  DEPT 
P.O.  BOX  2158,  YALE  STATION 
51  PRQPSPcCT  STREET 
MEW  HAVEN  CT  06520 

DR  DOUGLAS  SMITH 
KESTREL  INSTITUTE 
3260  HILLVIEW  AVE 
PALO  ALTO  CA  94304 


DR.  AUSTIN  TATE 

AI  APPLICATIONS  INSTITUTE 

UNIV  OF  EDINBURGH 

30  SOUTH  BRIDGE 

EDINBURGH  EHl  IHN  -  SCOTLANO 


DIRECTOR 

DARPA/TTO 

3701  N.  FAIRFAX  OR.,  7TH  FL 
ARLINGTON  VA  22209-1714 


DR  STEPHEN  F,  SMITH 
ROSOTICS  INSTITUTS/CMU 
SCHENLET  PRK 
PITTSBURGH  PA  15213 


OR.  ASRAHAH  WAK5MAN 
AFOSR/MM 

110  OUMCAN  AVE.,  SUITE  3115 
BOLLING  AF3  DC  20331-0001 


OR  JONATHAN  P.  STILLMAN 
GENERAL  ELECTRIC  CRO 
1  RIVER  RQ»  RH  K1-5C31A 
P.  Q.  BOX  8 
SCHENECTADY  NY  12345 

OR  EDWARD  C.T.  WALKER 
3SN  SYSTEMS  C  TECHNOLOGIES 
10  HQULTON  street 
CAMBRIDGE  MA  02138 


DR  BILL  SWARTQUT 
USC/ISI 

4676  ADMIRALTY  WAY 
MARINA  DEL  RAY  CA  00292 


DR  KATIA  SYCARA/THE  ROBOTICS  INST 
SCHOOL  GF  COMPUTER  SCIENCE 
CARNEGIE  MELLON  UNIV 
DOHERTY  HALL  RM  3325 
OITTS8URSH  PA  15213 

OR.  PATRICK  WINSTON 
MASS  INSTITUTE  OF  TECHNOLOGY 
RH  NS43-B1T 
545  TECHNOLOGY  SQUARE 
■CAM3RIOGE  MA  02139 

MR  JOHN  P.  SCHILL 
ARPA/ISO 

3701  N  FAIRFAX  ORIVE 
ARLINGTON  VA  22203-1714 


MR.  MIKE  .ROUSE 
AFSC 

7800  HAMPTON  RD 
NORFOLK  VA  23511-6097 


MR.  OAVIO  E.  SMITH 
ROCKWELL  INTERNATIONAL 
444  HIGH  STREET 
PALO  ALTO  CA  94301 


JEFF  R0THEM8ERG 

SENIOR  COMPUTER  SCIENTIST 

THE  RANO  CORPORATION 

1700  HIN  STREET 

SANTA  MONICA  CA  90407-2138 

DR  MATTHEW  L.  SINSSERG 
CIRL,  1269 

UNIVERSITT  OF  OREGON 
EUGENE  OR  97403 


MR  IRA  GDLOSTEIN 

OPEN  SW  FOUNDATION  RESEARCH  INST 
ONE  CAMSRIDGE  CENTER 
CAMBRIOGE  MA  02142 


NR  JEFF  GROSSMAN,  CO 
NCCOSC  ROTE  OIV  44 
5370  SILVERGATE  AVE,  ROOM  1405 
SAN  DIEGO  CA  92152-5146 


JAN  GUNTHER 

ASCENT  TECHNOLOGY,  INC, 
64  SIDNEY  ST,  SUITE  330 
CAMSRIDGE  MA  02139 


OR  LYNETTE  HIRSCHMAN 
MITRE  CORPORATION 
202  BURLINGTON  RO 
BEDFORD  MA  01730 


DR  ADELE  E.  HOWE 
COMPUTER  SCIENCE  DEPT 
COLORADO  STATE  UNIVERSITY 
FORT  COLLINS  CO  80523 


OR  LESLIE  PACK  KAELSLINS 
COMPUTER  SCIENCE  DEPT 
BROWN  UNIVERSITY 
providence  RI  02912 


OR  SU3SARAO  KAMSHAJ^PATI 
DEPT  OP  COHPUTER  SCIENCE 
ARIZONA  STATE  UNIVERSITY 
TEMPE  AZ  85287-5406 


DR  PRAOEEP  K-  KHOSLA 
ARPA/ITO 

3701  N.  FAIRFAX  OR 
ARLINSTON  VA  22203 


OR  CARLA  SOMES 
ROME  LABQRAT0RY/C3CA 
525  BROOKS  RD 
ROME  NY  13441-4505 


OR  MARK  T.  MAY3URY 
ASSOCIATE  DIRECTOR  OF  AI  CENTER 
ADVANCED  INFO  SYSTEMS  TECH  G041 
MITRE  CORP,  BURLINGTON  RO,  MS  K 
3EDF0R0  «A  01730 

MR  OONALD  P.  MCKAY 
PARAMAX/UNISYS 
P  0  BOX  517 
PAOLI  PA  19301 


OR  MARTHA  E  POLLACK 
OEPT  OF  COMPUTER  SCIENCE 
UNIVERSITY  Or  PITTSBURGH 
PITTSBURGH  PA  15260 


OR  EDWINA  RISSLAND 
DEPT  OF  COMPUTER  S  INFO  SCIENCE 
UNIVERSITY  OF  MASSACHUSETTS 
AMHERST  MA  01003 


OR  MANUELA  VELOSO 
CARNEGIE  MELLON  UNIVERSITY 
SCHOOL  OF  COMPUTER  SCIENCE 
PITTSBURGH  PA  15213-3891 


OR  DAN  WELD 

OEPT  OF  COMPUTER  SCIENCE  S  ENG 
MAIL  STOP  FR-35 
UNIVERSITY  OF  MASHINGT0^3 
SEATTLE  WA  93195 
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OR  TOM  GSRVET 
ARPA/ISC 

3701  NORTH  FAIRFAX  DRIVE 
ARLINGTON  VA  22203-1714 


MR  JOHN  N.  ENTZHINGSR,  JR. 
ARPA/DIRO 

3701  NORTH  FAIRFAX  DRIVE 
ARLINGTON  VA  22203-1714 


LT  COL  ANTHONY  yAISANEN,  PHD 
COMMAND  ANALYSIS  GROUP 
Ha  AIR  M03ILITY  CQMMANO 
402  SCOTT  DRIVE,  UNIT  3L3 
SCOTT  AFS  IL  62225-5307 


DIRECTOR 

ARPA/ISO 

3701  NORTH  FAIRFAX  DRIVE 
ARLINGTON  VA  22203-1714 


OFFICE  OF  THE  CHIEF  OF  NAVAL  RSCH 
ATTN:  MR  PAUL  QUINN 

CODE  311 

800  N.  QUINCY  STREET 
ARLINGTON  VA  22217 


DR  GEORGE  ERGUSON 
UNIVERSITY  OF  ROCHESTER 
COMPUTER  STUDIES  SLOG,  RM  732 
WILSON  BLVO 
ROCHESTER  NY  14627 


DR  STEVE  HANKS 

DEPT  OF  COMPUTER  SCIENCE  &  ENG*G 
UNIVERSITY  OF  WASHINGTON 
SEATTLE  WA  98195 


OR  WILLIAM  S-  MARK 
LOCKHEED  PALO  ALTO  RSCH  LAB 
DEPT  9620,  SLOG  254F 
3251  HANOVER  ST 
PALO  ALTO  CA  94304-1187 

OR  ADNAN  DARWICHE 
INFORMATION  t  DECISION  SCIENCES 
ROCKWELL  IMT’L  SCIENCE  CENTER 
1049  CAMINO  00$  RIGS 
THOUSAND  OAKS  CA  91360 
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DR  JAMES  CRAWFORD 
CIRL,  1269 

UNIVERSITY  OF  OREGON 
EUGENE  OR  97403 


ROBERT  J.  KRUCHTEN 
HQ  AMC/SCA 

203  W  LOSET  ST,  SUITE  1016 
SCOTT  AFB  IL  62225-5223 
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MISSION 

OF 

ROME  LABORATORY 


Mission.  The  mission  of  Rome  Laboratory  is  to  advance  the  science  and 
technologies  of  command,  control,  communications  and  intelligence  and  to 
transition  them  into  systems  to  meet  customer  needs.  To  achieve  this, 
Rome  Lab: 


a.  Conducts  vigorous  research,  development  and  test  programs  in  all 
applicable  technologies; 

b.  Transitions  technology  to  current  and  future  systems  to  improve 
operational  capability,  readiness,  and  supportability; 

c.  Provides  a  full  range  of  technical  support  to  Air  Force  Materiel 
Command  product  centers  and  other  Air  Force  organizations; 

d.  Promotes  transfer  of  technology  to  the  private  sector; 

e.  Maintains  leading  edge  technological  expertise  in  the  areas  of 
surveillance,  communications,  command  and  control,  intelligence,  reliability 
science,  electro-magnetic  technology,  photonics,  signal  processing,  and 
computational  science. 

The  thrust  areas  of  technical  competence  include:  Surveillance, 
Communications,  Command  and  Control,  Intelligence,  Signal  Processing, 
Computer  Science  and  Technology,  Electromagnetic  Technology, 
Photonics  and  Reliability  Sciences. 


